# Mermaid Semiconductor Implementation Plan

Approved September 30, 2026. The user approved all eleven batches, named the semiconductor mermaid, selected mermaid.tide.casa for the interface, and authorized continuation through every batch without further approval checkpoints. The first software release is implemented and qualified within the scope recorded in Mermaid Release Report.md; inherited suite failures and broader performance/energy objectives remain explicit.

Mermaid will start as a working software twin and an engineering blueprint for a hybrid chip concept: a semiconductor-qubit block alongside classical Bangel, predictive, and neural processing. The user selected this direction and a balanced speed-and-energy operating mode. The twin will let us test workloads, inspect where time and energy go, and compare design choices before making physical hardware claims.

The recovered thermoelectric work will be part of the standard architecture. We will use the working label **Mermaid cooling**, with its source identity **MJPS Thermodynamics / MJos Peltier–Seebeck Thermal Orchestration** beside it. The exact remembered nickname was not recovered, but the underlying work was found and will be reused.

## Agreed direction and remaining choices

| Item | Current decision |
| --- | --- |
| Architecture | User selected hybrid semiconductor qubits plus classical Bangel, predictive, and neural processing. |
| Default operating mode | User selected balanced speed and energy. Fastest and lowest-energy modes remain comparison options. |
| Cooling work | User requested reuse even if the recorded name differs. Include the recovered MJPS thermoelectric model as a standard subsystem. |
| Batch authorization | Approved. Continue all eleven batches, including deployment, without further approval checkpoints. |
| Physical technology | Proposed initial reference: a small silicon spin-qubit block and classical controller. The reference is silicon MOS electron-spin inspired with a proposed 1.2 K scenario target; material, foundry process and physical dimensions are not established. |
| Product destination | mermaid.tide.casa, replacing the previous proposed address. Hosting and domain configuration will be resolved in Batch 11. |

The initial engineering blueprint will explain functional blocks, interfaces, timing, power domains, thermal paths, packaging assumptions, and verification needs. Fabrication layouts, foundry rule checks, tape-out, and a manufactured device require a later hardware program. A software twin will become a calibrated physical twin only when real device and calibration data are attached.

## What the framework currently provides

The primary source checkout is clean at revision `229548f13a4856455b3d30d408cf845fb5b557fc`. The following inventory is based on source inspection. “Source present” means an implementation was found; fresh qualification runs belong to Batch 1.

| Subsystem | Available capability and standard integration |
| --- | --- |
| Elsa, independent JP admission, Joanna | General Bangel 1.0 compilation, admission, bounded calculations, and identity-bound receipts. This is the current execution chain. |
| Joanna scheduler, GIN, replay, SDK and API | Bounded scheduling, temporal states, interval and clock calculations, transport boundaries, and replay. Logical event/allocation counts require a separate energy model. |
| MJos Predictive Model | Development package with Bangel forecast/comparability calculations and dual admitted workers. Host processes supply transport, supervision, and isolation. Forecasts remain advisory until separately qualified. |
| MJ Neural Net and original MJ-Bangel-Neural baseline | Associative recall, relational discrimination, bounded nine-node layers, command-transition prediction, and diagram overlays. Include both as an implementation and comparison baseline, without double-counting the shared lineage. |
| MJ Memory Recall | Bangel scoring, context/identity checks, spatial projection, and command prediction. Python supplies catalog loading and SQLite persistence. |
| MJ Decision | Bangel candidate ranking and mode/precedence logic, with host-supplied review and health gates. Advisory selection does not grant execution authority. |
| Thermoelectric reference | Separate Bangel 0.1 MJPS profile for steady thermoelectric proposals. Python implements the physical equations and bounded optimizer; the package has no physical controller. |
| Paper adapters and semiconductor calculations | Computational and documentary adapters. F-152 thermal update, F-230 thermal predicate, F-232 byte accounting, and F-233 wake/reserve predicate are present. Workload power, geometry, charge integration, and semiconductor profile isolation need new contracts and implementation. |
| Managed .NET toolchain | Compiler, admission, numerical, runtime, and SDK source exists. Fresh parity is unverified; qualify Python first and treat .NET parity as a separately tracked portability deliverable. |

The historical Physics 0.1 qubit/gate listings and MJ.23.R2.ACT four-family architecture supply design requirements. The recovered current compatibility parser does not supply a working gate/Born-measurement/noise simulator. A quantum simulator therefore needs recovery and qualification or new implementation.

DRO collection, Pearl retention, the neurological umbrella, and other named family roles will appear in the standard capability manifest with their evidence status. The existing semiconductor integration is explicitly **PLANNED_ONLY_NO_PHYSICAL_ARTICLE**. Course names, paper profiles, and proposed family names do not establish additional fabricated processors.

## Proposed execution and system boundaries

```text
Browser interface: controls, diagrams, plots, evidence inspection
                         |
Host service: transport, catalogs, persistence, isolation, job orchestration
                         |
General Bangel 1.0 -> Elsa -> independent JP admission -> Joanna -> receipt
                         |
       Predictive / Neural Net / Memory Recall / Decision kernels
                         |
       Explicit versioned adapters and shared state/energy contracts
                /                               \
Quantum simulator or later hardware adapter    Separate Bangel 0.1 MJPS
                                              thermoelectric reference
```

Bangel will express supported calculation and decision kernels. Browser rendering, persistence, process isolation, complex quantum-state simulation, and the preserved MJPS physical kernel will be named as host components. Source written in Python or browser JavaScript will retain those identities. An adapter will translate validated data between profiles; it will not silently treat their grammars or representations as interchangeable.

MJos will supply the documented predictive and architectural context. Its role is not evidence that a complete bootable operating system already exists. Prediction and neural advice will begin in shadow mode. Comparison policies may use them inside the simulation, while independent admission and result checks remain enforced.

## Approved implementation batches

The user's agreement authorizes work in the stated order and scope. Each batch ends with inspectable outputs and its listed checks. Dependencies may run in parallel when they use independent state. Failed checks remain visible and guide the next bounded change.

| Batch and purpose | Concrete deliverables | Dependencies | Acceptance checks | Decisions within the batch |
| --- | --- | --- | --- | --- |
| **1 Source lock and measurable specification** — turn discovery into a reproducible starting point | Versioned capability manifest covering every available core/plugin/component and referenced role; source/license/profile hashes; fresh existing checks in an isolated copy in this workspace; workload and metric specification; gap register | User approval received | Every included subsystem has a source, version, host role, evidence status, and check result. Historical results remain distinct from new runs. Quantum/MJPS/general profiles cannot be conflated. Completed book/course projects remain untouched. | Pin the baseline and select the exact supported environment; record missing dependencies rather than borrowing an old pass. |
| **2 Hybrid architecture and interface contracts** — define what we are designing | System block diagram; candidate semiconductor-qubit reference; classical processor/software mapping; data/control/authority interfaces; memory, power, reset, clock, and thermal domains; state and provenance schema | 1 | Every block has inputs, outputs, units, budgets, time meaning, failure state, and responsibility. Observed, predicted, simulated, and measured values remain distinct. Chip cores and software services are labeled separately. | Choose reference qubit technology/topology and operating-envelope assumptions. Confirm which proposed roles require new functionality. |
| **3 Bangel execution and subsystem adapters** — make current capabilities usable together | Elsa–JP–Joanna integration; bounded scheduler and GIN adapters; receipt/replay support; separate MJPS adapter; standard subsystem registry; explicit extension contracts for DRO/Pearl and open semiconductor formulas | 1–2 | Supported programs reproduce expected outputs; wrong profile/root/receipt, UNKNOWN, unit mismatch, cancellation, and exhausted budgets produce correct refusal or HOLD. New formulas use an independent oracle. No implicit authority passes between modules. | Select service/API form; decide which open formula contracts the first release needs. Keep independent four-family runtime work outside this initial scope unless added explicitly. |
| **4 Quantum states and timing** — give the qubit block an inspectable model | Bounded complex-state backend; gate, measurement, reset, and declared noise models; replayable draws/seeds; ideal small circuits; shared event timeline; modeled gate/readout/reset and classical handoff durations | 2–3 | Independent analytic checks for normalization, unitarity, Bell correlations, and small search circuits; declared noise checks; reproducible sampling and basis ordering; capacity and unsupported-operation limits. Model time, host elapsed time, and future physical time are separate. | Recover a suitable backend or select a host simulator; fix capacity and numerical tolerances before benchmarks. Initial proposal: 2–8 ideal qubits, smaller bounded noisy cases. |
| **5 Predictive and neural processing** — include documented computation as standard | MJos forecast workers/guardian; neural baseline and overlay; Memory Recall; Decision; held-out evaluation; fixed/predictive/neural/combined policy modes; context, namespace, and provenance checks | 3; modeled workload traces from 4 as available | Chronological evaluation prevents future leakage. Predictions never become observations. Forecast error, coverage, recall/context correctness, and scheduling benefit are scored separately. Missing review/health/context gates remain effective. Dual workers and storage costs are counted. | Select input features and horizon; use the balanced policy as the default. Qualify advice before enabling simulated control. |
| **6 Mermaid cooling and energy accounting** — reuse the thermal work and connect it to chip loads | Preserved steady Peltier/Seebeck profile; separate thermal/electrical ledgers; qualified transient thermal network or documented recovery; heat-sink/contact/property-curve models where required; workload load mapping; cooling policy comparisons | 2–3; may run alongside 4–5 | Reproduce source fixture results as simulations. Check `Qh = Qc + Pin`, signed bus balance, losses, parameter/temperature limits, uncertainty corners, and UNKNOWN/calibration HOLD. Compare identical loads with reference cooling, TEC-only, and TEC+harvesting. Transient steps converge under refinement. | Place thermoelectric modules in the valid thermal stage. Select coefficients and heat-rejection assumptions. A cryogenic qubit stage requires its own validated model; the warm-stage fixture is not that model. |
| **7 Workloads and optimization** — test speed and energy together | Versioned benchmark suite; raw run records; fixed-scheduler and subsystem ablations; balanced/fastest/efficient configurations; latency–energy–quality plots; reproducible benchmark report | 4–6 | Identical jobs, inputs, result-quality thresholds, seeds, machine, and accounting boundaries. Include compile, transfer, retries, workers, storage, cooling, and failures. Report p50/p95 latency, successful throughput, J per completed job, temperatures, coverage, and uncertainty. | Choose the demonstrated operating point from measured/modelled tradeoffs. Missed targets are results, not grounds to relabel model values as measurements. |
| **8 Engineering blueprint** — turn the tested architecture into reviewable engineering views | Functional and processor maps; qubit connectivity; timing lanes; power tree; thermal stack and heat-flow view; memory/interconnect layout; packaging concept; interfaces/parameter sheets; design assumptions and hardware evidence plan | 2, 4–7 | Every drawn block maps to a contract and evidence status. Dimensions are schematic unless justified. Power and heat paths close their ledgers. Proposed devices and unresolved fabrication/calibration details are explicit. | Select the reference embodiment and resolve contradictions from benchmark/cooling results. Record what a hardware partner must validate. |
| **9 mermaid.tide.casa twin interface** — make the system understandable and usable | Local engineering interface with clickable topology, workload controls, quantum/classical timeline, thermal map, energy ledger, processor inspector, source/evidence labels, and exportable run receipts | 3–8 | Replayed jobs yield identical substantive results. Each chart distinguishes modeled/predicted/measured values and displays units. Controls expose all standard subsystems and operating modes. Desktop/mobile/accessibility checks; bounded updates keep the interface responsive. | Use a public educational/engineering viewer as the proposed first release; device credentials and physical control need a separate contract. |
| **10 Integrated validation and release evidence** — determine what the complete twin proves | Requirement-to-evidence matrix; end-to-end and independent numerical checks; replay/failure/cancellation checks; benchmark reproduction; dependency/profile inventory; release package and limitation report | 1–9 | No unresolved material contract or correctness defect is hidden by a green build. Failed/held jobs remain in denominators. Independent reference results agree within declared tolerances. Performance and energy claims match their actual evidence boundary. | Accept the supported release envelope; defer unsupported features with named gaps. Portability requires checks in each claimed environment. |
| **11 Hosting and deployment** — deliver the approved twin at the intended address | Confirmed mermaid.tide.casa host/domain route; staged preview; immutable release/deployment receipt; public smoke checks; monitoring and rollback instructions | 10; hosting identity/access resolved | Correct address serves the qualified version over HTTPS; API and replay work; no secrets in public assets; existing unrelated sites remain intact; rollback restores the prior release where one exists. | Resolve hosting and domain ownership/access. Publish only within the agreed deployment scope after the concrete release is ready. |

## Workloads and proposed targets

“Maximum speed” and “minimum energy” need a defined job and a correct result. These are proposed engineering targets for the first twin, not achieved results or physical device specifications. Batch 1 will freeze them before optimization and record any evidence-backed change.

| Objective | Proposed target and comparison |
| --- | --- |
| Correctness first | Deterministic contract fixtures match independent expectations. Small ideal quantum calculations agree within a declared tolerance, initially `1e-10` for normalization/probability checks. Sampling results use predeclared statistical tests. |
| Balanced speed and energy | Aim for at least **15% lower p95 end-to-end latency** and **20% lower modeled system energy per successful job** against the fixed-policy twin on the frozen mixed suite, with unchanged required result quality and success/coverage. Report a tradeoff frontier if both targets cannot be met together. |
| Predictive usefulness | Compare MAE, signed bias, answered/requested coverage, and interval coverage/width with last-observation and simple moving-average baselines on the same chronological held-out cases. Establish error/coverage requirements before enabling simulated control. Analog spread is not automatically a calibrated prediction interval. |
| Cooling usefulness | Reduce whole-system energy or improve thermal headroom at the same completed workload and result quality. Report peak/steady temperature, cooler power, rejected heat, settling time, and uncertainty. The chosen device envelope sets temperature limits. |
| Interface responsiveness | Proposed p95 visible update within 250 ms for the bounded default scene, measured separately from simulated gate/thermal time. Heavy jobs must support progress and cancellation. |
| Reproducibility | Record revision, profile, input identity, environment, seed/draw rules, warmup, repetitions, and raw outputs. Initially use at least 30 timed repetitions after warmup; report uncertainty and extend sampling when results are inconclusive. |

The initial suite will cover:

1. Bell correlations and controlled bit-flip noise as correctness workloads; small search/phase circuits only after backend support is demonstrated. These examples do not establish quantum advantage.
2. Chronological forecast cases and neural/recall tasks with identity conflicts, ambiguous matches, missing evidence, and valid decisions.
3. Mixed compute traces with bursts, idle periods, transfers, wake/restart reserves, deadlines, and cooling loads; compare fixed, predictive-only, neural-only, and combined policies.
4. Matched thermal scenarios: cooling disabled where valid, reference heat rejection, TEC-only, and TEC plus Seebeck harvesting, including an unavailable-harvest case.

Independent mathematical references validate results. A same-host classical reference provides a software benchmark; a future physical quantum advantage claim needs equivalent application-level classical work, complete hardware data, equal output quality, and uncertainty. Simulator runtime alone cannot supply that claim.

## How Mermaid cooling will be evaluated

The recovered hybrid fixture declares a 12 W cooling demand, a 12 W external power limit, 0.25 W auxiliary draw, converter efficiency 0.95, and driver efficiency 0.9. Its stored tests expect 15.78 W robust cooling, 0.12005 W harvested electrical power, and about 11.29 W external draw. These illustrative fixture outputs were freshly reproduced in the first release; the recovered thermal suite passed94 methods. They remain model values, not semiconductor measurements.

The model uses separate harvesting and cooling modules. Pump power, Joule heating, thermal conduction, converter losses, and heat released at the hot side must be counted. Harvested energy is credited once at the defined system boundary. Any energy used to create the harvesting temperature difference must also be included; the twin cannot fund its cooler by reusing the same heat as an uncharged source.

The present kernel is steady and uses constant properties. A profile refers to a separate transient thermal network, but that implementation was not found in the packaged source. The first release delivers a separate warm RC transient extension and repeated matched cooling ablations; see Mermaid Modeled Ablation Benchmark.md. Temperature-dependent property curves, calibrated contact models and real semiconductor heat-load data remain later qualification work in Batch 6. Warm-stage thermoelectric behavior will not be extrapolated into a cryogenic qubit stage without a valid model.

The governing cooler relation includes rejected heat as well as electrical input; this matches [Ferrotec’s manufacturer modeling reference](https://thermal.ferrotec.com/technology/thermoelectric-reference-guide/thermalRef11/). Full-system quantum energy studies also include control electronics, wiring, and cooling rather than using gate energy alone; see [Fellous-Asiani and colleagues](https://arxiv.org/abs/2209.05469).

## Evidence and later physical qualification

The interface and blueprint will distinguish **documented**, **source present**, **freshly executed**, **simulated estimate**, and **physical measurement**. Every result keeps its source/model version, input, units, time basis, and uncertainty where known. A missing input remains missing, not zero.

A later physical program would need a selected device/process, measured parameters, calibrated electrical/thermal instruments, traceable workload and power records, heat-rejection measurements, repeated comparative tests, and hardware/simulation agreement. Physical quantum performance additionally needs device compilation, calibration, job identity, gate/readout results, and appropriate fidelity/error checks. That program is outside the first software release and is not implicitly authorized by agreeing to these implementation batches.

## Source record and approval

The companion **Mermaid Semiconductor Source Evidence.md** records the recovered sources, processors, profiles, semiconductor gaps, cooling equations, and relevant book/paper locations. Structured discovery used all 8,914 journal records and the 49-chapter book as searchable sources; it did not require reading the entire 18,632-page PDF.

All planning files and later project work remain in this chat’s workspace. The completed book, encyclopedia, courses, and earlier framework checkouts are references and will not be edited as part of this project.

All eleven batches are approved. The hybrid architecture, balanced default, and reuse of the recovered cooling work are selected. Continue implementation, validation, and deployment without further approval checkpoints; report factual evidence and unresolved external limitations as they arise.